In the data communication field involving computers and networking, there is a basic concept of the "dialog", which in computing circles, involves the exchange of human input and the immediate machine response that forms a "conversation" between an interactive computer and person using it. Another aspect of the "dialog" is the reference to the exchange of signals by computers communicating on a network. Dialogs can be used to carry data between different application processes, and can be used to carry data over computer networks. In computer networking, dialogs can be considered to provide data communication between application processes running on different systems or different hosts. Further, dialogs can carry data between application processes running on the same host.
There is a generally recognized OSI (Open System Interconnection) standard for worldwide message transfer communications that defines a framework for implementing transfer protocols in 7 layers. Control is passed from one layer to the next, starting at the layer called "the Application Layer" in one station, proceeding to the bottom layer, over the channel to the next station, and back up the layers of a hierarchy which is generally recognized as having 7 layers. Most of all communication networks use the 7-layer system. However, there are some non-OSI systems which incorporate two or three layers into one layer.
The layers involved for network Users are generally designated from the lowest layer to the highest layer, as follows:
1. The Physical Layer;
2. The Datalink Layer;
3. The Network Layer;
4. The Transport Layer;
5. The Session Layer;
6. The Presentation Layer; and
7. The Application Layer.
The Application Layer 7 (top layer) defines the language and syntax that programs use to communicate with other programs. It represents the purpose of communicating. For example, a program in a client workstation uses commands to request data from a program in a server. The common functions at this Application Layer level are that of opening, closing, reading and writing files, transferring files and e-mail, executing remote jobs, and obtaining directory information about network resources.
The Presentation Layer 6 acts to negotiate and manage the way the data is represented and encoded between different computers. For example, it provides a common denominator between ASCII and the EBCDIC machines, as well as between different floating point and binary formats. This layer is also used for encryption and decryption.
The Session Layer 5, coordinates communications in an orderly manner. It determines one-way or two-way communications, and manages the dialog between both parties, for example, making sure that the previous request has been fulfilled before the next request is sent. This Session Layer also marks significant parts of the transmitted data with checkpoints to allow for fast recovery in the event of a connection failure. Sometimes the services of this session layer are included in the Transport Layer 4.
The Transport Layer 4, ensures end to end validity and integrity. The lower Data Link Layer (Layer 2) is only responsible for delivering packets from one node to another). Thus, if a packet should get lost in a router somewhere in the enterprise internet, the Transport Layer will detect this situation. This Transport Layer 4 ensures that if a 12 MB file is sent, the full 12 MB will be received. OSI transport services sometimes will include layers 1 through 4, and are collectively responsible for delivering a complete message or file from a sending station to a receiving station without error.
The Network Layer 3 routes the messages to different networks. The node-to-node function of the Datalink Layer (Layer 2) is extended across the entire internetwork, because a routable protocol such as IP, IPX, SNA, etc., contains a "network address" in addition to a station address. If all the stations are contained within a single network segment, then the routing capability of this layer is not required.
The Datalink Layer 2 is responsible for node-to-node validity and integrity of the transmission. The transmitted bits are divided into frames, for example, an Ethernet, or Token Ring frame for Local Area Networks (LANs). Layers 1 and 2 are required for every type of communication operation.
The Physical Layer 1 is responsible for passing bits onto and receiving them from the connecting medium. This layer has no understanding of the meaning of the bits, but deals with the electrical and mechanical characteristics of the signals and the signaling methods. As an example, the Physical Layer 1 comprises the RTS (Request to Send) and the CTS (Clear to Send) signals in an RS-232 (a standard for serial transmission between computers and peripheral devices) environment, as well as TDM (Time Division Multiplexing) and FDM (Frequency Division Multiplexing) techniques for multiplexing data on a line.
It will be seen that present-day communication systems generally will have a high band-pass capability of data throughput for high speed network technologies which may occur at rates on the order of 100 MB per second, to 1 gigabit per second.
However, sometimes the problems of delays or latency may be high. Latency is generally considered to be the time interval between the time a transaction issues and the time the transaction is reported as being completed. In certain systems having a high latency, the round-trip time for two clients communicating with each other to complete a data request can be on the order of milliseconds.
The delays in communication due to "latency" will be seen to occur from conventional communication systems due partly to overhead in the communication layers, and generally is especially due to latency in the layers below the Transport Layer 4, i.e., Layers 3, 2 and 1. In high speed data communication systems, the Transport Layer 4 is still seen to impart substantial latency in communications.
The present Connection Library Interface between the Network Provider and the MCP operating system involves specialized functions and operating sequences for enhancing the speed of dialog exchanges and for providing more efficient methods for data transfer.
A brief summary of certain interfaces in the background of the present Connection Library (CL) interface will be discussed initially starting with the Network Data Path interface 30 of FIGS. 1, 2, and 3A.
NETWORK DATA PATH INTERFACE (30): Currently as will be noted in FIG. 3B, Unisys Corporation's computer architecture supports two interfaces to the Network Provider(s) 20--the standard user-visible interface through the Port Files 14, and--a system software synchronous interface called Sync.sub.-- Port CB 16 (Connection Block). Sync.sub.-- Port users can avoid copying incoming data in certain cases and can make decisions about where to copy it because they are allowed to look at the data before copying.
The Sync.sub.-- Port interface can also be used to eliminate processor switching in the input data path for certain applications. Often though, the strict rules about what could be processed in-line as part of notification of input, resulted in the process switch merely being moved into the Sync.sub.-- Port user's code.
The BNA and the TCP/IP type Network Providers provide the Sync.sub.-- Port interface (which is used primarily by COMs.sub.-- PSHs and the Unisys-supplied DSS's), with a performance boost. "DSS" refers to Distributed System Services, while PSH refers to Protocol Specific Handler.
The Cooperative Services Interface (12) of FIGS. 1, 2, 3B and FIG. 5, provides an additional performance benefit over the Sync.sub.-- Ports by allowing a Network Provider (20) and a DSS (10) to bypass the Port File (18) code in the Master Control Program 80 (MCP), by allowing it to share data and by relaxing the rules about what can be performed as part of an "input" notification.
The interface between the MCP's Port File 18 (FIG. 3A) code and the Network Providers (the PIE interface 18c) was earlier implemented as an old-style Connection Block 18b, FIG. 3B, (CB) so that by changing this to a "Connection Library" (CL), 18c, this provided a performance advantage by eliminating the MCP overhead required to access the entry points exported via a prior type of Connection Library (CB) using Connection Blocks.
Because Connection Libraries (CL) (see Glossary) can export data items in addition to procedures, this change also allows for the Port File Code and the Network Providers to share dialog-oriented locks. Such sharing allows an elaborate lock/deadlock avoidance code, previously employed, to be simplified greatly, thereby not only improving performance, but also closing numerous of the timing windows. Sharing locks in this way also obviates the need for several of the more complex interfaces in the priorly used interfaces.
The Unisys E-mode based portions of the Network Providers (20) were previously enabled to communicate with their ICP-based (Integrated Communication Processor--Glossary item 18) components via an interface provided by the NP Support, 35, FIG. 3B. The NP Support 35 provided a complex path Connection Block (CB) interface 20b which the Network Providers used to get the data when they wished to send into an I/O capable buffer, and the CB generated and parsed the QSP (Queue Service Provider) protocol, in order to "multiplex" the numerous dialogs (that the Network Providers had) over a single Physical Unit Queue.
In the new, improved architecture, "multiple queues" are now provided between the Unisys E-mode environment and a given Channel Adapter (CA) environment, thus obviating the need for this previous multiplexing function and eliminating the de-multiplexing bottleneck on the NP/Controller stack on the input.
Since the QSP (Queue Service Provider) protocol generation is very simple, that function is now moved into the Network Provider, 20. This re-distribution of function allows the NP Support 35 (FIG. 3B) to be "eliminated" from the Data Path. In fact, the double-dashed line through the NP Support 35 (FIG. 3B) is now accomplished by means of a Read/Write directly to the Physical I/O procedure 32 (FIG. 3B) providing transport to the Channel Adapter (CA) environment except in the case of the old Integrated Communication Processors (ICPs), where multiple queues still must be simulated in the NP Support 35, and FIG. 3B.
To avoid the necessity of copying data in order to assemble Network Provider-generated header data, and data from multiple-use buffers into one contiguous memory area, the ability to "Gather" data from multiple buffers on the output is added to the I/O processor in input/output module IOM 40. The Physical I/O 40 simulates "Gather" in cases where the I/O processor does not support it directly.
Additionally, a "Scatter" feature is provided so that a single incoming data message can be split across multiple buffers. This is used by the Network Provider(s) to ease their memory management problems, and they thus have a consolation code channel (in Network Provider NP 20, FIG. 3B) to cope with the cases where Scatter is not provided by the I/O processor.
As a result of the improvements to the Network Data Path Interface 30, there is a reduced need to copy data, throughput performance is enhanced, more transmissions can occur simultaneously by reducing routing overhead at destination end points, there is a greater capacity for multi-threading and the protocol stacks can more efficiently handle the use of buffers.
FIG. 3B shows a specialized drawing of FIG. 3A where a number of interfaces are shown between DSS 10 and the Network Provider 20. The cooperative interface (12) with Connection Library connects directly between the DSS 10 and the Network Provider 20. The DSS 10 also has connections to Ports 18 through the Port File 14 and also via the Sync Port Connection Block 16.
Ports Unit 18 provides two types of connections to Network Provider 20. These are seen as the PIE-CL 18c (Process Inter-Communication Element Connection Library) and also the PIE-CB 18b (Process Inter-Communication Element Connection Block). Further in FIG. 3B, there is seen the low level kernel 28 which has the Network Processor Support (NPS) Unit 35 and which connects to Physical I/O 40 through the Logical Input/Output, LIO 34. Additionally, the Network Processor Support Unit 35 also connects to the Physical I/O 40 via the new Direct Interface 32.
FIG. 3B shows the elliptical dotted lines indicating the "old" prior data transfer pathway which involved the Connection Block 20b, the Network Processor Support 35 and the Logical I/O 34. Similarly, an elliptical dotted line indicates the "new" path which involves the new Connection Library (CL) System 20m which also operates through the Network Processor Support 35 and through the new Direct Interface 32 over to the Physical I/O 40 (Input/Output Module, IOM).
The Physical I/O 40 communicates with a number of processors which are indicated as Network Processors 50 such as the Integrated Communication Processor 42, the Emulated Communication Processor 44 and the DICP 46 (the Direct Integrated Communication Processors) or each of which also include can include the Channel Adapters (CA).
The Network Processors (FIGS. 3B) are involved in a Network Processor environment 50 which utilizes a Control Unit 56, a Path System Service 54 and a Path Select Unit 52.
As seen in FIG. 3B, a Network Provider 20 provides for "scatter consolation" functions and further indicates various data paths which are indicated with the dotted lines to indicate support for compatibility and the small vertical dashed lines which indicate the new paths for high speed datacom operations.
Likewise, the Network Processor Support (NPS) Unit 35 enables multiple queue simulation functions and also indicates, via the small dashed lines, channels for high speed data communications. The heavily dotted lines indicate support for compatibility between the new connection library system 20m and the old connection block 20b system.
A Distributed Application Supervisor (DAS 22) connects to the kernel 28, while also providing output to a path input control for CB, 23i, and a Supervisor CB/CL control 23s. These last two blocks feed to the Network Processor Support Module 35, which provides an output to the Logical I/O (LIO 34) and to the Physical I/O 32, and thence to I/O 40, whereby the Physical I/O 40 is a Simulation "Gatherer" to provide output to: the Integrated Communication Processor 42; or the Emulated Integrated Communication Processor 44; and/or to the Direct Integrated Communication Processor 44, and/or to the Direct Integrated Communication Processor 46, which provide communication to Channel Adapters (CA) in a Network Interface Card (NIC) of Network Processor 50.
Thus in summary, the architecture of FIG. 3B shows the old data path through the Connection Block 20b which is now supplanted by the new data path 30 which utilizes the Connection Library 20m. However, as was indicated earlier, the architecture of FIG. 3B may permit the use of the old path in addition to the use of the new path in order to provide compatibility for older systems which are not oriented to the new Connection Library Data Path Interface.